PCX 



WORLD INTEtlKTOAL PROPERTY ORGANIZATION 
International BuvetB 




(51) Intfirnational Patent Classificatimi ^ : 




(li) Intcrnatioiial PubUcatiim Number: 


WO OQ/46666 


G06F 9/00 


(43)'lDtenwtloiial PuWicatliMi Date 

' 1 "^-^ ^ " 


10 August 2000 (IOjOS.00) 



(2X) IntMnattonal Application Nmnben PCr/US00«>27n 
(»)Int«ii>8tioii8lI1HiigDat« 2 Febnaiy 2000 (02i)2A» 



(30) Priority Data: 
09/243.101 



2 Febnioy 1999 (02X099) US 



Oil AppUcanfe SUN M1C310SYSTEMS. INC. [US/US]; 901 San 
^' KioRoad. M/S PAU)1-321. Palo AI.O.CA 94303 (US). 

(72) iDventow: SCHWABE. Judiih, Ei 1600 Ea«t TTuri Avenw, 
San Majeo. CA 94401 (US). SUSSER. Jodwa. B4 
216 Dorland Street. San Francisco, CA 94114 (US). 

(74) Aeent: BEYER, Steve. HA Beyer & Weaver. LLP. TX>. Box 
^ «059. Palo Alio. CA 94306 (US). 



BR, BY, CA. CH, CN, CR, CU. CZ. DE, DK, DM, EE, 
ES FL GB, GD,GE.GH, GM.HR.hu, ID, lU IN, IS. JP, 
KE,KG,KP,KR,KZ.LC.LK,U<, LS, LT, LU, LV, MA, 
MD, MG, MK, MN, MW. MX. NO, NZ. PL, PT, RO, RU. 
SD, SE. SG, SI, SK, SU TJ, TM, TO, TT. it; UA, UG. 
UZ, VN. YU. ZA. ZW, ARIPO patent (GH, GM, KE, LS, 
MW, SD, SL, SZ, TZ. UG, ZW), Eurasian patent (AM. AZ, 
BY KG, KZ. MD. RU. TJ, TM), European patent (AT, BE, 

c:h! cy. de, dk, es, pi, fr, gb, gr, ie. it. lu, mcx 

NL, FT, SE), OAPI patent (BF, BJ, CP, CG, CI, CM, OA, 
GN. GW, ML. MR, NE, SN, TO,TQ>. 



Published ^ . uru^l 

Without iiOematUfiuU sean^ report and to be rtpubUahtd | 
upon receipt oftiiat report* 



^)-ntle: OBJECT-ORIENTED INSTOUCnON SET FCWRESOURCE^NSTRAINED DEVICES 



(57) Abstract 

A rcsouico-constrained device such as a smart card 
or the like includes memory for storing an application soft- 
ware program comprising an object-onented..venfiablc, platp 
fonn-rdepcndent, type-safe and P?'"}^*f ^^^"J^^^^^ 
structions. The device can also include a virtual machine 
implemented on a microprocessor 

is capabfe of executing the sequence of mstrucuons. Each 
instruction indudes an operation code, and each data mai^ 
ulation instruction is specific to a particular data type. The 
application program can be stored on a computer-ieadaWe 
rnSlium priw to being received by the lesource^onstrained 
device. Methods of using such an application prog^ in- 
chidfaig accessing the program ov<^ the Internet and down- 
loading it to a smart card, also are disclosed. 
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OBJECT-ORIENTED INS TRHmON SRT FOR 
RESOURCE-rONSTRAir ^yTI DEVICES 

BACKGROUND 

The present invention relates, in general, to object-oriented, architecture-neutial 
programs for use with resource-constrained devices such as smart cards and the like. 

A virtual machine is an abstract computing machine generated by a software 
application or sequence of instructions which is executed by a processor. The tenn 
"architecture-neutral" refers to programs, such as those witten.in the Java"^ programming 
language, which can be executed by a virtual machine on a variety of computer platforms 
having a variety of different computer architectures. Thus, for example, a virtual machine 
being executed on a Windows™-bascd personal computer system will use the same set of 
instructions as a virtual machine being executed on a UNIX™-based computer system. Tbt 
result of the platform-independent coding of a virtual machine's sequence of instnictions is a 
stream of one or more bytecodes, each of which is, for example, a one-byte-long numerical 
code. 

Use of the Java programming language has found many applications including, for 
example, those associated vnth Web browsers. 

The Java programming language is object-oriented. In an object-oriented system, a 
"class" describes a collection of data and methods that operate on that data. Taken together, 
the data and methods describe the state of and behavior of an object 

Java also is verifiable such that, prior to execution of an application written in the 
Java programming language, a determination can be made as to whether any instruction 
sequence in the program will attempt to process data of an improper type for that bytecode or 
whether execution of bytecode instructions in the program wiU cause underflow or overflow of 
. an operand stack. 

A Java™ virtual machine executes virtual machine code written in the Java 
programming language and is designed for use with a 32-bit architecture. However, various 
resource-constrained devices, such as smart cards, have an 8-bit or 16-bit architecture. 

Smart cards, also known as intelligent portable data-carrying cards, generally are 
made of plastic or metal and have an electronic chip that includes an embedded microprocessor 
to execute programs and memory to store programs and data. Such devices, which can be 
about the size of a credit card, typically have limited memory capacity. For example, some 
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smart cards have less than one kilo-byte ( 1 K) of random access memory (RAM) as weU as 
limited read only memory (ROM), and/or non-volatile memory such as electrically erasable 
programmable read only memory (EEPROM). The limited architecture and memory make it 
impractical or impossible to implement the full Java Virtual Machine on the device. 

Furthermore, smart cards come with a variety of proccssois and configurations. 
Thus, it is desirable to provide a platform-independent programming language that can be 
executed on such a resource-constrained device. 

SUMMARY 

In general, a verifiable, object-based, type-safe and pointer-safe instruction set is 
described for application software programs which can be downloaded to and executed on a 
range of resource-constrained devices. 

According to one aspect, an application software program includes an object- 
oriented, verifiable, type-safe and pomter-safe sequence of instructions residing on a computer- 
readable medium. The program can be loaded to and executed by a resource-constrained 
device that is based on an architecture of fewer than 32 bits, such as a 16.bit or 8-bit 
architecture. 

According to another aspect, an application software program includes an object- 
oriented, verifiable, type-safe and pointer-safe sequence of instructions residing on a computer- 
readable mediuin. The program can be loaded to and executed by a resource-constrained 
device having random access memory with a capacity of no more than about 64K. 

Various implementations include one or more of the following features. For 
example, each instruction can include an 8-bit operation code, and the sequence of instructions 
can be hardware platform-independent In some implementations, the sequence includes 
instructions that were previously converted from at least one Java class file with at least some 
references to a constant pool uansformed to inline data. For example, the instructions can 
include operation codes and operands. Some references to the constant pool can be inlined into 
operands, and some references to the constant pool can be inlined into operation codes. 

Similarly, in some embodiments, the instructions can be executed by a device that 
supports multiple data types. The sequence of instructions can include data manipulation 
30 instructions each of which is specific to a particular data type. In some implementations, the 
data type associated with each data manipulation instruction is selected from among one of the 
following types: an 8-bjt signed two's complement integer numeric type, a 16-bit signed two's 
complement integer numeric type and a 32-bit signed two's complement integer numeric type. 
Additionally, the instructions can be executed by a device that supports multiple reference 
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types each of which is selected from among one of the foHowing types: a class type, an 
interface type arid an array type. Furthermore, the program can include one or more composite 
instructions for performing an operation on a current object 

According to another aspect, a resource-constrained device includes memory for 
5 storing an application software program comprising an object-K)ri.ented, verifiable, type-safe 
and pointer-safe sequence of instructions. The device also includes a virtual machine 
implemented on a microprocessor. The virtual machine is capable of executing the sequence 
of instructions. In various embodiments, the device may be based on a limited architecture or 
may have a limited amount of memory. For example, in some implementations, the device 
10 includes random access memory having a cai»city of no more than about 64K. In other 

emboduncnts. the microprocessor is based on an architerture of less than 32 bits, for example, 
a 16 or 8-bit architecture. 

In other embodiments, an application-specific integrated circuit (ASIC) or a 
combination of a hardware and firmware can be used instead of a virtual machine running on a 

IS microprocessor. 

In one particular application of Ae invention, the resource-constrained device is 8 
smart card. The smart card can include a virtual machine implemented on a microprocessor, 
wherein the virtual machine is capable of executing a sequence of instructions such 9S those 
described above. 

20 According to another aspect, methods are disclosed for using an application 

software program including an object-oriented, verifiable, type-safe and pointer-safe sequence 
of instructions. The software program can be received in a resource-constrained device 
having, for example, either limited memory or based on a limited architecture. The sequence 
of instnictions then can be executed on the resource-constrained device. In some 

25 implementations, the software program can be accessed over a computer network such as the 

Internet prior to downloading it onto the device. When the program is downloaded to the 

resource-consu-ained device, constant pool indices that appear in the received set of 

instructions can be transformed to conresponding data values. 

Various implementations include one or more of the following advantages. By 

30 supporting many, although not all, of the features of the Java language and by using the same 
semantics as the Java class files, platform- independent virtual machine code can be written to 
be executed by a smart card or other resource-constraned device. 

The instniction set can inline certain data, which would otherwise appear as part of 
a constant pool, directly into operation codes or operands. Thus, the instniction set itself can 
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incoiporaie cert^n infonnaiion that would otherwise be stored in and obtained from a constant, 
pool if one were using the Java class file format. By inlining some of the information directly 
into the instruction set, the size of the constant pool can be reduced, which can help reduce the 
amount of memory required to store the constant pool and can improve the execution speed of 
the bytecode. In some cases, inlining the information directly into an operation code can 
reduce the number of operands required for a particular instruction. Further inlining of 
information from a constant pool when the program is downloaded to the rcsourcc-constmincd 
device can either eUminate the need to retain the constant pool on the device or reduce the sin 

ofthecoiistantpooL 

Other features such as composite instructions forperfonning operations on fhe 
current object and the explicit handling of 16.bit arithmetic can further reduce the length of. 

bytecode program. . j 

Other features and advantages will be readily apparent from the foUowmg detailed 
descripUon. the accomiranying drawngs and the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 illustrates an exemplary system including a virtual machine residing on a 

smart card according to the invention. 

no. 2 is a flow chart illustrating a method of providing executable code to a smart 

20 card according to the inventioa 

HGS. 3A and 3B iUustrate. respectively, an exemplary format of virtual machine 
instruction and an inner loop of execution of the virtual machine according to the invention. 

nOS. 4A and 4B are tables of an exemplary set of operation codes for the virtual 
machine listed in numerical order by operation code and in alphabetical order by mnemonic 
25 respectively. 

FIG. 5 is a list of data types which are supported by operation codes that exist »r 

multiple data types according to the invention. 

FIG. 6A illustrates the format of an "iipush" instruction according to the invention. 
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and 

FIG. 6B illustrates the fomiat of a corresponding "Idc" instruction in the Java class 
file format 

FIG. 7A illustrates the foimat of a "checkcast" instruction in the Java class file 
format, and 
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FIG. 7B illustrates the fomat of a "checkcast^ instruction according to the 

invention. 

FIG. 8A illustrates the fonnatof afamily of "getfield.T instructions according to 
the invention, and 

5 no. 8B illustrates the fonnat of a corresponding "getfield" instruction in the Java 

class file fonnaL 

FIG. 9A and 9B illusuate how an implementation program on the smart caid 
prepares virtual machine code for installation on the smart card according to one embodiment 
of the invention. 

,0 HGS. lOA and lOB illustrate alternative instructions for obtaining the same result 

according to the invention. . . .w. 

no. 1 1 A iUustrates bytecodes for carrying out a mathematical expression using tbe 

Java class file format, and 

HG. I IB Ulustrates bytecodes for carrying out the same mathematical expression 

15 according to the invention. 

FIG. 12 is partial, non-exclusive list of 
resource-constrained devices with which the invention can be used. 

DESCRIPTION 

A verifiable, object-based, type-safe and pointer-safe instruction set is described 
below for application software programs which can be downloaded to and executed on a rai^ 
of resource-constrained devices. Resource-constrained devices are generally considered to be 
those that are relatively restricted in memory and/or computing power or speed, as compared to 
conventional desktop computers and the like. Although the particular implementation 
discussed below is described in reference to a smart card, the invention can be used with other 
resource-constrained devices including, but not limited to. cellular telephones, boundary scan 
devices, field programmable devices, personal digital assistants (PDAs) and pagers, as well as 
oflier miniature or small footprint devices. 

Programs written with the instruction set described below are capable of bemg 
downloaded to and executed on resource-constrained devices having about sixty-four knc 
30 bytes (64K)ofRAM or less. Some ofthe resource-constrained devices in which such 

programs can be executed may have no more than about sixteen kilo-bytes ( 1 6K) of RAM and 
others may have no more than about four kilo-bytes (4K) of RAM. Many ofthe devices also 
have limited amounts of other memory, such as no more than about twenty-four kilo-bytes 
(24K) of ROM. or no more than about 16K of non-volatile memory such as EEPROH 
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Similarly, some resource-constrained devices are based on an architecture designed for fewer 
than 32 bits. For example, some of the devices which can be used with the invention are based 
on an 8-bit or 16-bit architecture, rather than a 32-bit architecture. Of course, applicatioiis 
using the instruction set described below are upward compauTjle and can be executed, fiw 
example, on other Java platforms provided equivalent device support is present. 

Referring to HCS. 1 and 2. development of an applet for a lesource-constrained 
device, such as a smart card 40, begins in a manner similar to development of other Java 
prograins. In other words, a developer writes one or more JAVA classes (step 60) and 
compiles the source code with a JAVA compiler to produce one or more class ffles 10 (step 
62). The applet can be run, tested and debugged, for example, on a workstation using 
simulation tools to emulate the environment on the card 40. When the applet is ready to be 
downloaded to the card 40. the class files 10 are converted to a converted applet (CAP) ffle 16 
by a converter 14 (step 64). The converter 14 can be implemented as a Java application being 
executed by a desktop computer. The converter 14 can accept as its input one or more export 
files 12 in addition to the class files 10 to be converted. An export ffle 12 contains naming or 
linking information for the contents of other packages that are imported by the classes being 

converted. , 

In general, the CAP file 1 6 includes aU the classes and interfaces defined in a smgle 
Java package and is represented by a stream of 8-bit bytes. All 16-bit and 32-bit quantities are 
constrocted by reading in tvw) or four consecutive 8-bit bytes, respectively. Among other 
things, the CAP file 16 includes a constant pool component 18 which is packaged separately 
from a method component 20. The constant pool component 18 can include various types of 
constants, ranging from numerical literals known at compile time to method and field 

references which are resolved either when the program is downloaded to the smart card 40 or 
at the time of execution by the smart card. The method component 20 specifies the set of 
instructions to be downloaded to the smart card 40 and subsequenUy executed by the smart 
card. Further details of the structure of an exemplary CAP file 16 are discussed in a 
publication by Sun Microsystems, Inc. entitled "Java Card Runtime Environment (JCRE) 2.1 
Specification," (1998) which is incorporated herein by reference in its entirety. 

After conversion, the CAP file 16 can be stored on a computer-readable medium 17 
such as a hard drive, a floppy disk, an optical storage medium, a flash device or some other 
suitable medium. 

The CAP file 1 6 then can be copied or transferred to a terminal 22 (step 66) such as 
a desktop computer with a peripheral card acceptance device (CAD) 24. In some 
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embodiments, the tenninal 22 can be connected, to a network (not shovm). such as the Internet, 
a local area network (LAN) or a wide area network (WAN), -hich communicates with other 
computing devices suchasaserver. In such situations, the CAP file 16 can be accessed and 
tnmsmitted to the tenninal 22 over the network. The CAP file 16 also can be provided to ^ 
terminal 22 using a carrier wave, such as a network data transmission. 

The CAD 24 allows infonnation to be written to and retrieved from the smart card 
40 The CAD 24 includes a card port (not shown) into which the smart card 40 can be 
bs'erted. Once inserted, contacts from a connector press against the surface comiection area on 

die smart card 40 to provide power and to permit communications with the smart caid. 
although, in other implementations, contactless communications canbeused. The te^^ 
dso includes an installation tool 26 which loads the CAP file 1 6 for transmission to the 

(step 68). 

The smart card 40 has an input/output (I/O) port 42 which can mclude a set«f 
contactsthn,ugh.whichprogram8,dataandothercommunicationsareprovided. 1hecard40 
also includes an installation tool 46 for receiving the contents of the CAP file 16 and preparmg 
the applet for execution on the card 40 (step 70). The installation tool 46 can be implemented, 
for example, as a Java program and can be executed on the card 40. The card 40 also h.. 
.memory, including volatile memory such as RAM 50. The card 40 also has ROM 52 andn«. 
volatile memory, such as EEPROM 54. The applet prepared by the controller 44 can be stox«l 

inthcEEPROM54. . , u- 

In one particular implementation, the applet is executed by a virtual machme 49 
running on a microprocessor 48 (step 72). The virtual machine 49. which can be referred to .3 
the Java Card™ Virtual Machine, need not load or manipulate the CAP file 16. Rather, the 
Java Card Virtual Machine 49 executes the applet code previously stored as part of the CAP 
file 16. The division of functionality between the Java Card Virtual Machine 49 and the 
installation tool 46 allows both the virtual machine and the installation tool to be kept 

xelativelysmalL , 

general, implementations and applets written for a resource-constramed platform 

such as the smart card 40 follow the standard rules for Java platform packages. The Jav» 

, Virtual Machine and the Java programming language are described in T. Lindholm et aL. The 

Java Virtual Machine Specification (1 997). and K. Arnold et al.. The Java Programming 

Language Second Edition, (1998). which are incorporated herein by reference in their entirety. 

Application programming interface (APD classes for the smart card platform can be written « 

Java source fJes which include package designations, where a package includes a number of 
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compilation units and has a unique name. Package mechanisms are used to identify and 
control access to classes, fields and methods. The Java Card API allows applications written 
for one Java Card-enabled platform to run on any other Java Card-enabled platfonn. 
Additionally, the Java Card API is compatible wth formal international standards such as ISO 
5 78 1 6, and industry-specific standards such as Europay/MasterCard/Visa (JEMV). 

The smart card platform of the present invention supports dynamically created 
objects including both class instances and arrays. A class is implemented as an ortension or 
subclass of a single existing class and its members are methods as weU as variables referred to 
as fields. A method declares executable code Aat can be invoked and that receives a fixed 
10 number ofvalues as arguments. Classes^ can define or implement Java interfiwes. An 
inter&ce is a reference type whose members are constants and abstract methods. 

Individual instructions stored in the CAP file 16 and subsequently downloaded to 
the smart card 40 include an 8-bit operation code (opcode) followed by either zero, one or 
multiple 8-bit operands (HG. 3 A). Some instructions have no operands and consist only of an 
13 opcode. The general form of the inner loop of execution of the Java Card Virtual Machine 49 
is illustrated in HG. 3B. When a method is invoked, the Java Card Virtual Machine 49 
allocates a fiame which has a set of local variables and contuns an operand stadt Many of 4b 
operation codes discussed below take one or more values fiom the operand stack of the cuneat 
frame, operate on them, and return resulte to the same stack. The operand stack abo is used to 
20 pass arguments to methods and receive method results. 

Values from Ae operand stack must be operated upon in ways that are appropriate 
to their types. The Java Card Virtual Machine 49 supports two kinds of data types: primitive 
types and reference types. The numeric primitive types supported by the Java Card Virtual 
Machine 49 are: (1) "byte", whose values are 8-bit signed two's complement integers; (2) 
25 "short", whose values are 1 6-bit signed tft'o's complement integers; and, optioiially, (?) "inf*. 
whose values are 32-bit signed two's complement integers. The Java Card Virtual Machine 49 
also supports a "retumAddress" type, whose values are pointers to the operation codes in the 
instructions for the virtual machine. The reference types supported by Uie Java Card Virtual 
Machine 49 are (1) "class" types; (2) "interface" types; and (?) "array" types. Those reference 
30 types are the same as the reference types used in the Java Virtual Machine. The Java Card 

Virtual Machine 49 is defined in terms of an abstract storage unit, which can be referred to as a 
word, which is sufficiently large to hold a value of the type "byte," "short," "reference," or 
"retumAddress." Two words are sufficiently large to hold a value of the type "int" Multiple- 
byte operand data is encoded in big-endian order, in other words, with the high-order byte first 
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Various keywords, which cannot be used as identifiers or names of declared 
entities, are supported by the Java Card Virtual Machine 49. The fiinction and use of those 
keywords is the same as the conesponding keywords in the Java programming language. 

The operation codes which form the executable program stored in the method 
5 component 20 of the CAP file 1 6 are designed to use the same semantics as that used in the 
class files 10 written in the Java language. Thus, for example, mathematical results and class 
hierarchies are preserved when the converter 14 transforms the Java class files 10 into the CAP. 
file 16. Nevertheless, as will be evident from the following description, a sequence of 
instructions that can be executed by the Java Card Virtual Machine 49 differs fiom programs 
,0 intendedsolelytoberunbyasystemincorporatingtheJavaViitaalMachine. Someofth. 
differences are due to the more limited support of datatypes present in the instiuction wtt 
• discussed below. Other differences result from the feet that the instmction set discussed bdow 
is designed to be executable by a virtual machine residing on a resource-constrained device. 
Some details of the instruction set arc intended to optimize the size or perfonnance of either 
,5 the Java Card Virtual Machine 49 or the programs nmning on it Such details include inlining 
constant pool data directly into the operation codes or operands, adding multiple versions . 
particular instmction to handle different data types, creating composite instructions 
operations on the current object, and explicidy handling 1 6-bit arithmetic. 

Referring to FIGS. 4A and 4B, an exemplary instruction set is provided fcr 
20 programstobeexecutedbytheJavaCardVirtualMachine49. Each instruction is identified 
by a coixesponding operation code (opcode) mnemonic and numerical representation. With the 
exception of two reserved opcodes, impdepl and impdep2. all of the opcodes typically can be 
used in a CAP file such as the CAP file 16, The instructions conesponding to the two reserved 
opcodes provide backdoors or traps to implementation-specific functionality implemented fa 
23 sofhmc and hardware, respectively. Accordingly, the two reserved opcodes typically do not 
properly appear in the CAP file 16. They are typicaUy used only in representations of 
programs that were placed on the smart card 40 by means other than receipt of a CAP file. 

As previously mentioned, each instruction includes an operation code foUowed by 
zero. one. or more operands. In other words, the instructions have the following general 
30 format: 

operation code 

operandi 

operandi 
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Each word in the instniction format represents a single 8-bit byte or "bytecode." The 
instruction's opcode is its numeric representation. Each instruction also has a corresponding 
mnemonic which is its name. However, only the numeric representation is present in the 
virtual machine code in a CAP file such as the CAP file 36. 
5 Each data manipulation instruction is specific to a particular data type. The 

instruction set corresponding to the operation codes listed inHG. 4A supports a subset of tbe 
features supported by the Java programming language- By supporting many, although not all. 
of the features of the Java language and by using the same semantics as the Java class files 10. 
platform-independent virtual machine code can be witten to be executed by tbe smart card 4^ 
10 or otherresotirce-ccnstrained device. 

As mentioned above, the instruction set for the Java Card Virtual Machine inlines 
certain data, which would otherwise appear as part of the constant pool 18. directly into the 
operation codes or operands. Thus, the instruction set itself mcoiporates certain mformation 
that would otherwise be stored in and obtained from a constant pool if one were using the Java 
15 class file format. Thus, when the one or more Java class files 10 are converted to the CAP file 
1 6, at least some references to a constant pool are transformed to inline data in the bytecodes 

associated with the CAP file. 

For example, if the virtual machine 49 supports the data type "mt," then the 
"iipush- operation code can be used to push an integer value onto the operand stack. 
20 general format for the "iipush-histnKtion is illustrated in no. 6A, and the foiinat of a 

corresponding "Idc" instruction from the Java class file format is shown in FIG 6B. The "Idc" 
instruction includes the operand "index" which is an unsigned byte that is an index mto a 
constant pool. In contrast, the "iipush" instruction, which is executable by the Java Card 
Virtual Machine 49, eliminates the need to refer to the constant pool when executing that 
25 instruction. Although the "iipush" instruction includes four operands, thereby increasing die 
length of the instruction, the slighUy longer program can be ofSet by the savings in memoiy ■■ 

space which is achieved by eliminating the need to store additional infonnation in the constant 

pool 18. 

Similarly, the "checkcast" operation code can be used to check whether an object IS 
30 of a particular type. The general format for the "checkcast" instruction for the Java Card ^ 
Virmal Machine 49 is illustrated in HG. 7A. and the fonnat of a corresponding "checkcasT 
instruction from the Java class file format is shown in FIG 7B. TTie data type for the Java Card 
Virtual Machine 49 has been inlined direcUy into the instruction, in contrast to die 
corresponding Java instruction in which the data type is obtained from a constant pool By 
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inlming some of the infonnation direcdy into the instruction srt^ 

1 8 that is stored in the CAP file 16 can be reduced. 

The foregoing examples iUustrate how the instruction set for the Java Card Vutual 
Machine 49 inlines some information directly into an operand. In some cases, an additional 
; form of inlining is provided by mlining information that would other>vise be stored mthe 
constant pool 18 directly into an operation code. n.us. for example, the instruction set for the 
Java Card Virtual Machine adds multiple versions of several instruction to handle different 
data types so that those instructions appear as members of a family of related instructio«s 
.hich share a single description, format and operand stack diagraxn. Each instruction in ^ 

0 familyofinstructionsimplicitiyspecifiesthedatatypeintheoperationcodeitselt The^ 
inHG Sprovidesalistofthedatatypeswhicharcsupportedbyinstructionsthatexistfer 
n^ultiple data types. Wide and composite forms ofinstructions are not listed. Refemngto 
no 5 aspecific instruction. ^viththedatatypeincoiporatedintotheoperationcode.rs 
obtained by replacing the "T" in the instmction template in the opcode column by the lett« 
15 representingthetypeinthetypecolumn. Where die column for a particular instruction is left 
blank, then no instruction exists supporting the particular operation on that data type. For 
example, there is a "load" instruction for the data type -short." but there is no "load- 
instruction for the data type "byte." ^ 

With instructions that implicitiy incorporate the data type into the operation code. 
.0 theprogramcanoperatemorequicldyandwithlessda.aonthesni3rtc«d40t^ 

other^^se be required. Those advantages arise because the data type is directly encoded m the 
i^ctions rather than being obtained fiom an entry in the constant pooL For example^ ^ 
consider the family of "getfield.r instructions, which includes the insHuctions "getfield... 
-getfield b.- -getfield s" and "getfield.L" The general fonnat of the -getfieW.T" 
25 instructions for use with the Java Card Virtual Machine 49 is illustrated in HG. 8 A. which 
contrasts with the fonnat of the corresponding "getfield" instmction in the Java class file 
format as shown in no. 8B. In die instructions for the Java Card Virtual Machine 49 (HG. 
8 A) the data type has been inlined not only into the instruction, but it has been inlined directly 
into'the operation code. On die one hand, such fcamres can reduce the amount of infonnataoo 
30 stored in the CAP file 16 and also can reduce the number of operands required for the 
particular instruction. On the otiier hand, Uiose features expand die number of distitua 

operation codes. .^^^^ , 

Whereas the type of inlining discussed with respect to the "iipush" and checkcast 

opcodes can be advantageous for instnictions that tend to be less frequently used, the type of 
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inlining discussed with respect to the "getfield_r family of instructions can be advantageous 
particularly for instructions that tend to be used more frequently. 

The foregoing examples illusUate how the instruction set for the Java Card Virtual 
Machine 49 inherently inlines certain information. Another fonn of inlining infonnation can 
5 occur when the CAP file 1 6 is downloaded to the smart card 40, as explained below. 

The installation tool 46 on the smart card 40 can be platform-specific and allows the 
actual storage of the contents of the CAP file 16 to be detennined based on the particular 
platform receiving and preparing the virtual machine code for execution. Thus, in some 
implementations, the CAP file 16 may be stored on the smart card 40, or other resouice- 
10 constrained device, in a manner that diffenifiom the numncr in which it was recci^ 

smart card. For example, in some cases, when the CAP file 16 is instaUed on the card 40, the 
installation tool 46 can link the contents of the CAP file so that the size of the constant pool 18 
can be reduced, and m some cases, so that the constant pool need not be retained or stored on 
the card That can be accomplished by converting the constant pool indices that appear as part 
15 of the code in the CAP file 18 to the coixesponding data at the time of installation, as Ulustrated 
in HGS. 9A and 9B. For example, an index to the constant pool 16 can be replaced by n 
index to the appropriate field in the object Thus, the virtual machine code stored on the can! 
40 wiU already have the data incorporated within h prior to the time of execution. The virtual 
machine code, with the constant pool 1 8 removed, reduces some of the indirection inherent in a 
20 program which uses a constant pooL The amount of memory required to store the bytecodes 
on the smart card 40 can, therefore, be reduced, and the execution time for the program also 
can be reduced. Of course, in other implementations, the installation tool 46 may retain the 
constant pool 18 when the CAP file 16 is downloaded to the smart card 40. 

As previously mentioned, the instruction set for the Java Card Virtual Machine also 
25 includes composite instructions for performing operations on the current object In other 

words, some of the instructions that are executable by the Java Card Virtual Machine 49 allow 
multiple instructions to be collapsed into a single instruction. In particular, instructions that 
include a "this" operation, such as the family of "getfield.T.this" instructions and the family 
of "putfield.T.this" instructions, effectively concatenate multiple instructions. In general, flie 
30 "this- operation operates on the current object For example, to fetch a field from the current 
object, one could use a combination of the "aload.O" instruction and a "getfield.a" instruction 
as shown in HG. 1 OA. Alternatively, one can use the single instruction "getfieldjljhis" as 
illtistrated in HG. 1 OB. Use of the latter instruction can result in a smaller and faster program 
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code. AS previously noted, such features are pardcularly advantageous in reso^^^ 

devices such as the smart card 40. . ^ _^ 

Tte totr««o. «. to fl« to. C«d Virt«ia M«hto. toriles 16-b,. an,hm«c 
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What is claimed is: 

1. An application sofWare program comprising an object-oriented, verifiable, type- 
safe and pointer-safe sequence of instructions residing on a computer-readable mec&im, 
wherein the program can be loaded to and executed by a resource-constrained device that is 

5 basedonaprocess<»ardutectureoffewerthaa32Wtl. 

2. The software program of claim 1 wherein the program can be executed by a 
resource-constrained device based on a 16-bit processor arcHtectuie. 

3. The software program of claim 1 wherein the program can be executed by a 
resource-constrained device based on an 8-bit processor architectuie. 

10 4. The software program of claim 1 wherein each instruction includes an Wnt 

operation code. 

5. The software program of claim I wrhcrein the sequence of instructions is hardvraie 
platform-independent 

6. The software program of claim 1 wherein the instructions were converted from at 
least one Java class file and wherein at least some references to a constant pool were 

transformed to inline data. 

7. The software program of claim 6 wherein the instructions comprise operation codes 
and operands and wherein at least some references to the constant pool are inUned udo 
operands in at least some of the mstructions. 

8. The software program of claim 6 wherem the instructions comprise operation codes 
and operands and wherein at least some references to die constant pool are inlined into 
operation codes in at least some of the instructions. 

9. The software program of claim 1 wherein the instructions can be executed by a 
virtual machine running on a microprocessor residing on the resource-constrained device. 

25 10. The software program of claim 1 wherein the instnictions can be executed on a 

portable smart card. 

11 . The software program of claim 1 wherein the instructions can be executed by a 
device that supports multiple data types, wherein the sequence of instructions includes data 
manipulation instructions, and wherein each data manipulation instruction is specific to a 

30 particular data type. 

12. The software program of claim 1 1 wherein the data type associated with each data 
manipulation instruction is selected from among one of the following types: an 8.bit signed 
two's complement integer numeric type, a 16-bit signed two's complement integer numeric 
type and a 32-bit signed two's complement integer numeric type. 

14 
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13 ThesoftvraicprogramofclaimllwheicmthemstmctioiBcanbeex 
device that supports multiple reference types and therein each reference type is selected fiom 
among one of the follovrfng types: a class type, an interface type and an array type. 

14. He software program of claim 1 wherein the program includes at least one 
composite instruction for pafotming an operation on a current object 

15 An application software program comprising an object-oriented, verifiable, type- 
safe and pointer-safe sequence of instructions residing on a computer-readable medimn. 
wherein the program can be loaded to and executed by a resource-constrained device havmg 
random access memory with a capacity of no more than about 64 kilo-byte.. ^ 

16 niesoftwareprogramofclaim 15 wherein theprogiamcanbeexecutedlqr* 
xesouxce-constrained device having random access memory with a capacity of no more ^ 

about 4 kilo-bytes. , j . ™ ojJt 

17. nxesoftwareprogramofclaimlSwhereineachmstrucUonrndudesanlMA 

, 15 therein the sequence of inst^ctions is hardware 

platform-indcpendett _».jfi„««t 
19 itesoftwareprogramofdaimlSwhereintheinstructionswereconvertedfiom^ 

least one Java class file and wherein at least some references to a constant pool were 

transformed to inline data. 
, 20 msoftwHreprogramof claim 19whereintheinstructionscompnseoperat«« 

codes and operands and wherein at least some references to the constant pool are inBned 
operands in at least some of the instructions. 

21 n.e software program of claim 19 v^^erein the instructions comprise operati« 
codes and operands and wherein at least some references to the constant pool are inline 

>5 operation codes in at least some of the instructions. 

2i -me software program of claim 15 wherein the instmctions can be executed by a 
virtual machine rimning on a microprocessor residing on the resource-constrained device. 

23. nie software program of claim 1 5 wherein the instructions can be executed on . 

portable smart card. ^^y^. 
30 24 nie software program of claim 15 wherein the instructions can be executed by • 

device that supports multiple data types, wherein the sequence of instructions bcludes da.. 
.anipuMion instructions, and wherein each data manipulation instruction is specific to a 
particular data type. 
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25. The software program of claim 24 wherein the data type associated with each data 
manipulation instruction is selected from among one of the following types: an 8-bit signed 
two's complement integer numeric type, a 16-bit signed two's complement integer numeric 
type and a 32-bit signed two*s complement integer numeric type. 
5 26. The software program of claim 24 wherein the instructions can be executed by a 

device that supports multiple reference types and wherein each reference type is selected from 
among one of the foUowing types: a class type, an interface type and an array type 

27. The software program of claim 15 wherein the program includes at least one 
composite instruction for performing an operation on a current object 
10 28. A resource-constrained de>dce comprising: 

memory for storing an application software program comprising an object-oriented, 
verifiable, type-safe and pointer-safe sequence of instructions; 

random access mcmoxy having a capacity of no more than about 64 kilo-bytes; and 
a virtual machine implemented on a microprocessor wherem the virtual machine is 
15 capable of executing the sequence of instructions. 

29. The device of claim 28 wherein the. microprocessor is based on an 8-Wt 

architecture* 

30. The device of claim 28 wherein the microprocessor is based on a 16-Wt 
architecture. 

31. "Hie device of claim 28 wherein each instruction includes an 8-bit operation code 

32. The device of claim 28 wherein the sequence of instructions is hardware platfonnr 
independent 

33 . The device of claim 28 wherein the insmicuons were converted from at least one 
Java class file and wherein at least some references to a constant pool are transformed to inline 
23 data. 

34. The device of claim 33 wherein the instructions comprise operation codes and 
operands and wherein at least some references to the constant pool are inlined into operands tn 
at least some of the instructions. 

35. Hie device of claim 33 wherein the instructions comprise operation codes and 
30 operands and wherein at least some references to the constant pool are inlined into operation 

codes in at least some of the instructions. 
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36 The device of claim 28 wherein the virtual machine supports multiple datatypes, 
wherein the sequence of instructions indudes data manipulation instructions, and wherem 

data manipulation instruction is specific to a particular data type. 

37. The device of claim 28 wherein the program includes at least one composite 
; instruction for perfonning an operation on a cunent object 
38 A resource-constrained device comprising: 

* memory for storing an application software program comprising an object-oriented., 
verifiable, type-safe and pointer-safe sequence of instructions; aiKi . 

a virtual machine implemented on a microprocessor that « based on an a«*.tecta«« 
0 oflessthan32bits.whereinthevirtualmachineiscapableofexec«tingthesequenceof 

instructions. 

39 A resoun^-constrained device comprising: 

* xnemory for storing an appUcation software program comprising an object^riented. 
verifiable, type-safe and pomter-safe sequence of instructioiis; 

^omaccessmemoryhavingacapaci1yofnomorethanabout641d^^^ 

aprocessorcapableofexecutingthesequenceofinstnictioia. 

40 mdeviceofclaimSPwhereintheprocessorisbasedonanS-bttarch^tecture. 

41. device of claim 39 wherein the processor is based ona 16-bit axchitect«e. 

42. A resource-constrained device comprising: 

20 memory for storing an application software program comprising an o^ect^rientcd. 

verifiable, type-safe and pointer-safe sequence of instructions; 

random access memory having a capacity of less than about 64 kdo-bytes. a»d 
an application-specific integrated circuit (ASIQ capable of executing the sequence 

of instructions. . 

23 43 TT,edeviceofclaim42whereintbeASICisbasedonan8-brtarchitect«e. 

44. n.e device of claim 42 wherein the ASIC is based on a 16-bit architecture. 
45 A smart card comprising: 

memory for storing an application software program comprising an object-oriented, 
verifiable, type-safe and pointer-safe sequence of instructions; and 
30 a virtual machine implemented on a microprocessor, wherein the vutual machine » 

capable of executing the sequence of instructions. 

46. -Ibe smart card of claim 45 wherein the virtual machine is substantially a Java Card 
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47. The smart card of claim 45 wherein each instruction includes an 8-bit operation 

code. 

48. The smart caid of claim 45 wherein the sequence of instructions is hardware 
platform-independent 

49. The smart card of claim 45 wherein the instructions were converted from at least 
one Java class file and wherein at least some references to a constant pool are transformed to 
inline data. 

50. The smart card of claim 45 wherein the instractions comprise operation codes and 
operands and wherein at least some references to the constant pool are inlined into operands in 
at least some of the instructions. 

51. The smart card of claim 45 wherein the instructions comprise operation codes and 
operands and wherein at least some references to the constant pool are inlined into operati<m 
codes in at least some of the instmctions. 

52. The smart card of claim 45 wherein the virtual machine supports multiple data 
types, wherem the sequence of instructions includes data manipulation insfructions, and 
wherein each data manipulation instruction is spedJBc to a particular data type. 

53. The smart card of claim 45 wherein the program includes at least one composite 
iiistmction for performing an operation on a cuxxent olgect 

54. A method of using an application software program including an object-oriented, 
verifiable, type-safe and pointer-safe sequence of instructions, the method comprising: 

receiving 4e software program in a resource-constrained device having random 
access memoiy with a capacity of no more than about 64 kilo-bytes; and 

* executing the sequence of instructions on the resource-constrained device. 

55. The method of claim 54 further including: 

storing the sequence of instructions on the resource-constrained device. 

56. The method of claim 54 further including accessing the software program over a 
computer network prior to downloading the program onto the resource-constrained device. 

57. The method of claim 54 further including accessing the software program over th 
Internet prior to downloading the program onto the resource-constrained device. 

58. The method of claim 54 further including: 

transforming constant pool indices that appear in the received set of instructions U 

corresponding data values. 
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